DPU/IPU关键价值：云计算的业务和管理分离
欢迎关注软硬件融合公众号：
编者按：
本文是作者《软硬件融合》书中内容的节选，聚焦云计算中的业务和管理分离。文中提出了发展的四阶段论：SmartNIC->DPU->IPU->eIPU，代表了作者对数据中心DPU/IPU发展的基本看法。
（标题）DPU/IPU关键价值：云计算的业务和管理分离
1 虚拟化视角：IO及管理的卸载
本节通过虚拟化的视角，来分析业务和管理的分离。主要是IO硬件虚拟化及IO相关工作任务的卸载。
1.1 IO虚拟化的发展迭代
面向服务器领域的CPU对虚拟化技术的支持已经相对成熟，通过CPU内部硬件机制，实现CPU、内存、中断、计时器等的硬件虚拟化。但CPU对IO的虚拟化只能部分支持，原因在于IO需要外部设备以及操作系统等软件的配合。
如图1所示，IO虚拟化技术经历了长期的演进，IO虚拟化的性能优化经过了一个长期的迭代过程：
阶段0，我们讨论的起始阶段，基于Virtio的IO类虚拟化。基于Virtio实现的IO类虚拟化，性能显著优于纯软件模拟。需要说明的是，Virtio是IO虚拟化的主流技术，是一种事实上的业界标准。虽然VT-d等技术已经出现，但很难成为IO虚拟化主流技术，具体原因会在接下来的阶段1具体说明。
阶段1，基于VT-d技术的直通映射。此方案虽然能够提供几乎完全硬件IO的性能，但并没有广泛应用，原因主要是传统的VT-d设备是一对一的，这样如果有多个VM，受服务器物理空间的限制，但很难有如此多的硬件设备，此方案不适合虚拟化场景。
阶段2，基于PCIe SR-IOV的IO硬件虚拟化机制以及提升性能的多队列机制。解决了单个设备完全硬件虚拟化成多个设备的问题以及更高的并行性能的问题。挑战在于不同的接口设备供应商提供的软硬件交互接口不一致，各家提供独立的驱动，甚至同一家供应商不同版本的设备接口都不一致。当通过直通机制，把硬件设备接口直接暴露给VM后，VM的迁移只能在相同的硬件平台迁移。相同的硬件平台，不是一个设备或一类设备相同，而是VM环境的所有设备硬件接口都一致。迁移的苛刻要求，对直通条件下的VM迁移造成非常大的挑战。
阶段3，硬件支持Virtio、NVMe等标准化接口。这样在整个主机产品层面，为客户提供一致的IO接口，统一VM镜像。一致性的平台，方便VM在不同的硬件服务器迁移，减少数据中心产品运维管理的压力。
阶段3.5，网络（虚拟网络）和存储（远程和本地存储）工作任务的数据面的卸载。网络和存储的工作任务是在Virtio的虚拟化设备之下的一层。虚拟化把IO卸载到硬件，原有下层的工作任务，也不得不卸载到硬件。从另一个角度，网络和存储的工作任务所占CPU资源越来越多，从CPU卸载到硬件也是必然的趋势。
阶段4，vDPA等迁移机制。当硬件支持了Virtio，基于vDPA的技术可以实现直通硬件设备的迁移解决方案。这里主要是通过数据面直通，控制面依然还是通过主机侧的vDPA软件来连接VM和设备的控制和状态交互。
阶段4.5，Hypervisor卸载。随着越来越多的硬件组件支持硬件虚拟化，Hypervisor所要完成的工作越来越少，更进一步的，我们把大部分Hypervisor的工作卸载到硬件中的嵌入式CPU。当Hypervisor卸载到硬件，vDPA等直通硬件的迁移解决方案也顺理成章的卸载到嵌入式软件中。留在主机侧的只保留一个非常简化的Lite Hypervisor，作为实际Hypervisor的代理，来完成简单的配置和调度工作。如果Hypervisor只是在上电初始启动的时刻承担资源创建、分配的功能，在需要迁移的时候辅助支持迁移（更进一步的，可以把设备相关的迁移处理卸载）。除此之外，在VM正常运行的情况，Hypervisor几乎不干涉VM的运行。这样可以认为，VM几乎独占处理器等计算机资源的，可以认为客户是几乎100% CPU资源占用的，也即是几乎100%物理机性能的。
阶段5，用户业务和管理完全的物理分离。当实现了Lite Hypervisor代理来卸载主要的虚拟化功能到硬件中，对主机的操作，只能通过Lite Hypervisor提供的API接口，其他访问完全无效，可以杜绝传统虚拟化场景对主机的ssh访问等安全风险。
图1 IO设备虚拟化演进
1.2 IO设备模拟及工作任务的硬件卸载模型
以Tx方向为例，虚拟化场景的网络数据处理路径：VM用户态程序->VM内核的TCP/IP协议栈->VM的虚拟NIC驱动->主机侧的模拟NIC->后台的网络工作任务（如VPC）-> NIC驱动->NIC设备接口->硬件以太网处理，然后把数据通过网络端口发送出去。
如图2所示，左边为通常的虚拟化场景的IO路径，右边为卸载后的IO路径。我们以网络为例，介绍从业务应用到硬件NIC出口的服务器中整个网络路径：
上层软件：如用户应用的http访问，也包括通过Socket访问的TCP/IP协议栈；
虚拟驱动：例如Virtio-net驱动，把协议栈过来的网络包按照Virtqueue的格式放在对应的Queue中；
虚拟设备：负责设备模拟以及IO的传输，把数据从VM的内存“搬运”到Host的内存；
工作任务：实现VPC的虚拟网络OVS处理，卸载分为两类，嵌入式软件卸载和硬件加速卸载；
实际的物理设备驱动：OVS封装好的网络流量，通过实际的网卡驱动发送到硬件，如果是硬件加速卸载，则不需要驱动；
实际的硬件设备：网络接口卡。
图2 IO设备模拟和工作任务的卸载模型
在虚拟化场景模拟的IO设备以及后台工作任务都是运行在主机侧的软件，一方面会占用较多的主机CPU资源，另一方面也会成为性能的瓶颈。因此，如图2右边，把IO设备和后台工作任务整体卸载到硬件中去，以此来加速整个IO路径的性能，整个加速的IO路径跟原有软件方案是一致的。
2 体系结构视角：以数据为中心
业务和管理分离，本质的原因是CPU的处理性能和IO处理性能的匹配度变低。从集中到分布，从“以计算为中心”的架构逐渐演化成“以数据为中心”的架构。
2.1 以计算为中心
大家所熟知的计算机架构，都是以计算为中心（Compute Centric）的。回顾计算机发展历史，冯·诺依曼架构是计算机的初始模型，其核心思想就是以计算为中心：控制器、运算器共同组成了中央处理单元CPU；内存作为CPU运行的“场所”，暂存CPU输入的数据、运行的中间状态以及输出的结果；IO设备作为输入输出，负责IO设备与内存间实际的数据交互。
随之而来的，一方面依靠工艺的持续进步，另一方面依靠各种优化设计技术（如流水线处理、多指令并行、分支预测以及指令乱序等机制），使得CPU性能得到爆发式的增长。而SRAM等内存由于设计工艺的约束（速率和容量不可兼得），很难随着CPU性能提升的同时同步提高容量和访问速率。于是，出现了分层的Cache机制来弥补这一性能差距。Cache的出现，进一步强化了CPU的中心地位
传统的IO设备性能，相比DDR等内存的性能还要更差一些。CPU不仅仅能够完成核心的计算处理，也能够同时完成与IO设备的控制和数据交互。随着操作系统、虚拟化等各种系统软件的出现，以及丰富多彩的上层应用软件，都是围绕着CPU这个核心的部件在发挥作用，逐渐构筑起软件和互联网的庞大生态体系。
2.2 处理性能的优化
IO性能快速提升，网络带宽从10Gbps逐渐提升到100Gbps，存储从SATA HDD过渡到NVMe SDD；然而CPU的性能提升逐渐遇到瓶颈，快速提升的IO性能，需要投入更多的CPU资源来处理IO交互和相应的数据处理。如图3，针对大量数据流的处理，整个处理延迟包括输入延迟、计算延迟和输出延迟。针对IO性能提升的挑战，以计算为中心的架构可以通过如下方式优化：
l优化输入输出延迟：硬件支持SR-IOV和多队列等机制，软件通过DPDK/SPDK或类似的方式，减少输入输出延迟。带来的代价是轮询方式需要独占CPU核，并且IO带宽较大时，则需要更多的CPU核。
l优化所有计算任务延迟：可以通过多核并行的方式来提升计算的性能，降低计算的延迟。IO的带宽增大，意味着更多的计算工作量，也意味着在保证一定的计算延迟的情况下，需要增加更多的CPU用于计算处理。
l优化一些计算任务：卸载一些通用的可以不需要主机参与的计算任务，减轻CPU计算的压力，例如把图3中的计算任务1和计算任务3完全卸载到硬件处理。
l优化到达CPU处理的数据量：通过软硬件结合，实现类似快慢路径的机制，例如把图3中的任务1和任务3卸载的基础上，还把任务2数据面硬件加速，这样大部分IO数据流不进入CPU。通过此机制，可以同时优化输入输出延迟和整个CPU计算任务处理的延迟。
图3 以计算为中心的延迟模型
要支持大量数据流计算任务卸载，势必需要独立、智能的IO处理单元来加速相关的数据处理加速。
2.3 以数据为中心
CPU实现了非常强大的Cache机制，Cache占用了很多的晶体管资源。Cache机制的设计，使得CPU非常适合计算密集型任务。根据时间局部性原理，最近使用的数据未来很可能会再次使用，这个规律在计算密集型任务是有效的。但是流式的数据处理，几乎没有Cache发挥的空间，而CPU密集的Load/Store操作，性能和功耗代价都很高。
随着微架构以及半导体工艺的约束，CPU的性能发展已经达到瓶颈；网络即将从25Gbps升级到100Gbps，存储NVMe接口的高速SSD得到大规模应用，IO性能的提升，依然看不到减缓的迹象。以计算为中心、集中式计算处理的架构，已经越来越不适应巨量数据时代的要求。而以数据为中心（Data Centric），通过数据流驱动计算的架构越来越成为一个重要的发展趋势。
如图4(a)所示，以计算为中心的架构，CPU是计算的主体；CPU与IO通信；GPU以及其他计算单元作为CPU的辅助计算单元，受CPU的调度；GPU与IO的数据交互需要通过CPU的协调来完成。
图4(b)为以数据为中心的架构，在此架构下，DPU负责所有计算单元的数据输入输出，包括CPU在内，每个计算单元是同等的地位，相互交互、相互协调来完成计算任务。同时，因为DPU专门负责IO的处理和数据传输，因此可以把一些IO处理任务在DPU中加速完成。让CPU、GPU等计算单元专注于业务的计算。
(a) 以计算为中心架构 (b) 以数据为中心架构
图4 服务器架构对比
2.4 DPU的定义
人工智能、物联网以及大数据技术的发展，推动着人类进入数据革命的时代，人工智能需要大量的数据以及大量数据的处理。2020年5月，NVIDIA首席执行官黄仁勋在一次演讲中表示，DPU（Data Processing Unit，数据处理单元）将成为继CPU和GPU之后，数据中心计算加速的第三个重要的平台（NVIDIA公司在2019年3月正式完成对Mellaonx公司的收购，当前为NVIDIA网络BU，本书中沿用通俗理解，依然采用Mellanox的称呼）。CPU用于通用计算，GPU用于加速计算，而DPU则负责数据移动过程中的数据处理。
DPU是一种SOC，包含如下一些典型特征：
片内的高性能CPU：能够在片内跟其他接口、加速处理单元的高效的数据交互；CPU不但承担其他硬件加速模块的控制面处理，也承担部分任务数据面处理；CPU也可以作为管理，承担CPU、GPU以及FPGA等计算单元的计算任务调度。
高性能网络接口：能够提供网络线速的处理性能，高效的把数据直接传输到CPU和GPU等计算单元。
丰富的灵活的可编程加速引擎：可优化人工智能和机器学习、安全、网络和存储等应用程序的性能。
DPU可以用作独立的处理单元，但通常将它们跟SmartNIC合并，代替传统NIC的位置，高效的处理IO计算任务，作用更大，效果更好。并且，有针对性的，在加入DPU的设计中，改进服务器架构，以数据为中心，更大限度的发挥DPU的作用，并且提供整体更高的处理性能。
3 AWS NITRO系统
NITRO系统是新一代EC2实例的基础平台，通过专用硬件和轻量级Hypervisor结合，它使得AWS能够更快地进行创新，进一步的降低客户成本，并带来更多好处，例如增强的安全性和新的实例类型。
AWS完全重构了虚拟化架构。传统的Hypervisor可以保护物理硬件和BIOS、虚拟化CPU、存储、网络并提供丰富的管理功能。借助NITRO系统来分解这些功能，将其分流到专用的硬件和软件，并通过将服务器几乎所有的资源交付给用户实例来降低成本。
Nitro系统用于为AWS EC2实例类型提供以下功能：高速网络硬件卸载；高速EBS存储硬件卸载；NVMe本地存储；远程直接内存访问(RDMA)；裸金属实例的硬件保护/固件验证；控制EC2实例所需的所有业务逻辑。
NITRO给AWS带来的好处：
更快的创新。NITRO系统是一个丰富的基础组件集合，可以通过许多不同的方式进行组装，从而使AWS能够灵活设计和快速交付EC2实例类型，并且具有越来越丰富的计算、存储、内存和网络选项选择。这种创新还产生了新的“裸金属”实例，客户可以通过虚拟化Hypervisor来虚拟化自己的裸金属实例，也可以没有Hypervisor，完全当作物理机来使用。
增强安全性。NITRO系统提供了增强的安全性，可以连续监视，保护和验证实例硬件和固件。虚拟化资源被转移到专用的硬件和软件上，以最大程度地减少攻击面。最后，NITRO系统的安全模型被锁定并禁止管理访问，从而消除了人为错误和篡改的可能性。
更好的性能和价格。NITRO系统实际上将主机硬件的所有计算和内存资源提供给您的实例，从而提高了整体性能。此外，专用的NITRO卡可实现高速联网，高速EBS和IO加速。CPU不必保留用于管理软件的资源，意味着可以节省更多的钱，这些钱可以转嫁给客户。
如图5，NITRO的物理形态为在服务器上的若干扩展板卡，通过不同的板卡组合，使得不同的EC2服务器实例类型实现不同的NITRO系统功能。这些卡分别实现了AWS NITRO系统的五个主要功能：
VPC NITRO卡。用于VPC的NITRO卡本质上是一个PCIe连接的网络接口卡。VPC NITRO卡的设备驱动程序是弹性网络适配器（ENA），该驱动程序已包含在所有主要的操作系统和发行版中。NITRO VPC卡支持网络数据包封装/解封装，实现EC2安全组，强制执行限制并负责路由。
EBS NITRO卡。用于EBS的NITRO卡支持EBS的存储加速。所有实例存储均以NVMe 设备的形式实现，并且EBS的NITRO卡支持透明加密，还支持裸金属实例类型。远程存储再次实现为NVMe设备，即使在裸金属环境中，也支持再次通过加密访问EBS卷，并且又不影响其他EC2用户和安全性。
用于实例的本地存储的Nitro卡。用于实例存储的NITRO卡还为本地EC2实例存储实现了NVMe。
NITRO控制器。NITRO卡控制器可协调所有其他NITRO卡、服务器Hypervisor和NITRO安全芯片。它使用NITRO安全芯片实现了信任的硬件根，并支持实例监视功能。它还为一个或多个用于EBS的NITRO卡实现了NVMe控制器功能。
NITRO安全芯片。NITRO安全芯片将所有IO捕获到非易失性存储中，包括BIOS和服务器上所有IO设备固件以及任何其他控制器固件。这是一种非常简洁的安全方法，通用CPU根本无法更改任何固件或设备配置。NITRO安全芯片还实现了信任的硬件根。该系统替代了数千万行用于UEFI并支持安全启动的代码。在启动服务器时，将其置于不受信任的状态，然后监测服务器上的每个固件系统，以确保未对它们进行任何未经授权的修改或更改。
图5 Nitro系统架构
另外，NITRO系统还实现了一个非常简单、轻量的Hypervisor，该Hypervisor通常处于静态状态，它使得AWS能够安全地支持裸金属实例类型。
4 Mellanox Bluefield DPU
如图6，Mellanox BlueField 2代是一个高度集成的DPU，集成ConnectX-6 DX网络适配器与ARM处理器核阵列，BlueField-2可为安全性、机器学习、云计算、边缘计算和存储应用程序提供灵活而高性能的解决方案，同时降低总拥有成本（TCO）。Bluefield-2 DPU的主要功能包括：
8个功能强大的64位ARMv8 A72内核，这些内核通过一个Mesh网络与DDR4内存控制器和双端口以太网（或InfiniBand）适配器互连；
支持两个10/25/40/50/100 Gbps或一个200Gbps以太网（或InfiniBand）网络端口；
一个用于连接ARM子系统的带外管理端口；
一个16通道PCIe Gen 3.0/4.0交换机，提供EP或RC功能；
集成了ConnectX-6 Dx网络适配器，提供网络相关处理加速；
硬件加速包括RDMA/RoCE功能以及加密、存储和网络加速；
依靠这些内置的硬件加速功能，结合ARM处理器阵列编程，可以实现复杂的自定义加速和控制路径。
图6 Mellanox Bluefield DPU架构图
BlueField-2 DPU，集成了各种安全加速，可以为数据中心提供隔离、安全性和加解密加速功能；通过ASAP2的网络加速方案以及完整的数据面及控制面卸载，可以高效、高性能的支持虚拟化、裸金属、边缘计算场景的快速部署；同时通过SNAP机制为存储提供完整的端到端解决方案。
5 总结
当前，业务和管理分离的趋势还在快速的演进过程中，有些公司已经发布了各自不同，甚至相互迥异的设计方案。具体实现有基于CPU、FPGA、ASIC或者多平台混合架构的实现方案。为了简化分析，这里不考虑具体实现所承载的硬件实体，我们只通过几个典型的功能演进来梳理整个问题的全貌：
第一阶段，智能网卡（SmartNIC）。管理侧网络后台任务是最先遇到资源消耗挑战的问题。典型的如OVS，在25Gbps下占用的CPU资源已经非常显著。智能网卡就是为卸载网络相关工作任务而出现的。
第二阶段，数据处理器（DPU）。在智能网卡的基础上，更本质的，不仅仅是网络，而是整个IO相关的工作任务处理都会面临类似的挑战，因此DPU在网络卸载的基础上，加入了存储卸载以及虚拟化卸载的解决方案。
更进一步的，基础设施处理器（IPU，Infrastructure Process Unit）。站在云计算公司的角度，这个处理器平台不仅仅承载网络、存储以及虚拟化的卸载，也需要承担安全、管理、监控等各种管理面的功能，更为关键的是物理的隔离业务和管理：业务在CPU和GPU，管理在DPU，或者更准确的称为IPU。
更贴合用户需求的，弹性的基础设施处理器（eIPU，elastic IPU）。随着业务规模的进一步增大，云计算公司对底层芯片提出了新的需求。在传统芯片需求的基础上，其特殊需求体现在：差异化的产品开发、高效的业务卸载以及快速迭代。要支持功能扩展，传统的解决方案都是基于集成或独立CPU实现的软件功能扩展。未来的云计算场景，IO需要更加极致的性能，基于CPU的软件方案已经无法满足要求，需要通过硬件方式来实现高性能的功能扩展。也即eIPU方案，需要提供性能高效的、开发低门槛的硬件功能弹性。
（正文完）